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Résumé Une architecture logicielle décrit la structure d'un système informatique en spé- 
cifiant ses composants et leurs interactions. Projeter une architecture logicielle sur une im- 
plémentation est une tâche reconnue difficile. Un élément crucial de cette projection est la 
description architecturale des interactions entre les composants. La caractérisation de ces 
interactions peut être plutôt abstraite ou très concrète, fournissant plus ou moins de support 
de programmation et de possibilités de vérifications statiques. 

Nous explorons un point dans l'espace de conception entre les spécifications abstraites et 
concrètes des interactions de composants. Nous introduisons la notion de contrat d'inter- 
actions qui exprime les interactions autorisées. Cette déclaration architecturale permet la 
génération de support de programmation qui assure la conformité entre l'architecture et 
l'implémentation, et favorise diverses vérifications. Nous instancions notre approche sur un 
langage de description d'architectures pour les applications Sensé/ Compute/Control et dé- 
crivons les stratégies de compilation et de vérification associées. 

1 Introduction 

Une application Sensé/ Compute/Control (SCC) est une application qui interagit avec un en- 
vironnement extérieur. Ces applications se retrouvent dans des domaines comme la domotique, la 
robotique et l'informatique autonome. Développer une application SCC est complexe car l'implé- 
mentation doit prendre en compte l'interaction avec l'environnement. De plus, la correction est 
essentielle puisque un changement dans l'environnement peut avoir des conséquences irréversibles. 

Une application SCC peut être définie suivant un style architectural comprenant quatre types 
d'éléments organisés en couches : (1) les sources, en bas, obtiennent les informations de l'environ- 
nement ; (2) les opérateurs de contexte traitent ces informations ; (3) les opérateurs de contrôle 
utilisent ces informations raffinées pour contrôler (4) les actions, en haut, qui impactent finale- 
ment l'environnement. Projeter une architecture logicielle ayant un tel niveau d'abstraction vers 
une implémentation et maintenir cette projection sont des tâches reconnues difficiles. 

Dans cet exposé nous proposons une approche pour lier architecture et implémentation qui 
vise les applications SCC. Cette approche introduit la notion de contrat d'interactions permettant 
à un architecte de déclarer quelles sont les interactions qu'un élément de l'architecture a le droit 
de réaliser (Section [2]). Cette notion de contrat d'interactions est dédiée au style architectural 
SCC dans le sens où un contrat d'interactions ne peut, syntaxiquement, décrire que les interac- 
tions autorisées par le style. Les contrats d'interactions sont utilisés pour générer un support de 
programmation qui va guider le travail d'implémcntation par les développeurs tout en maintenant 
la conformité avec l'architecture (Section [3]). L'architecte peut aussi utiliser les contraintes expri- 
mées par les contrats d'interactions pour vérifier un ensemble de propriétés allant au delà de la 
conformité (Section 2]). 



2 Contrats d'interactions 

Le but d'un contrat d'interactions est de décrire les interactions autorisées d'un opérateur au 
sein d'une application SCC. Ce contrat d'interactions est un triplet constitué des informations sui- 
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vantes : la condition d'activation permet d'indiquer quelles sont les interactions capables d'activer 
l'opérateur ; les données requises permettent d'indiquer les interactions supplémentaires autorisées 
pour chaque condition d'activation ; les actions à entreprendre permettent d'indiquer la réponse 
appropriée à chaque activation (émission d'une information pour un opérateur de contexte ou 
commande d'une action pour un opérateur de contrôle). En résumé, les contrats d'interactions 
guident le travail de l'architecte en lui proposant un cadre de spécification dédié au style SCC. 

3 Support de programmation 

Nous avons intégré les contrats d'interactions dans DiaSpcc, un langage de description d'ar- 
chitectures dédié aux applications SCC. À partir d'une architecture en DiaSpec, un générateur 
de code produit un framework de programmation Java dédié. Ce framework de programmation 
généré contient une classe abstraite pour chaque élément de l'architecture. Cette classe abstraite 
générée contient des méthodes pour faciliter Pimplémentation des éléments ainsi que des décla- 
rations de méthodes abstraites permettant d'implémenter la logique applicative. Implémcntcr un 
élément DiaSpec nécessite donc de créer une sous-classe de la classe abstraite générée correspon- 
dante. En conséquence, dans cette approche, un architecte peut changer l'architecture et générer 
un nouveau framework de programmation sans écraser le code des développeurs. Les changements 
dans l'architecture qui ont un effet sur le code déjà implémenté sont révélés par le compilateur 
Java assurant par là la conformité de Pimplémentation avec l'architecture. 

Chaque contrat d'interactions d'un opérateur se projette vers la déclaration d'une méthode 
abstraite dans la classe abstraite générée correspondante à l'opérateur. En particulier, (1) la condi- 
tion d'activation influence le nom de la méthode abstraite ainsi que son premier paramètre ; (2) les 
données requises se projettent vers autant de paramètres représentant des fonctions permettant 
d'exécuter l'interaction supplémentaire ; (3) les actions à entreprendre se projettent vers un ou 
plusieurs paramètres supplémentaires ainsi que vers le type de retour de la méthode. 

Le framework de programmation est généré de façon à guider les développeurs dans Pimplé- 
mentation de l'application ainsi qu'à les limiter à ce que l'architecture autorise. En particulier, un 
contrat d'interactions se projette vers une méthode abstraite qui fournit en paramètre tout ce qui 
est nécessaire à Pimplémentation de la logique applicative de l'opérateur. De plus, la déclaration 
de cette méthode impose au développeur de respecter les contraintes de l'architecture, assurant 
ainsi la conformité entre l'architecture et Pimplémentation. 

4 Support de vérification 

Les contrats d'interactions rendent explicites des informations sur le flot de données et per- 
mettent des vérifications statiques. Par exemple, avec les contrats d'interactions, il est possible de 
savoir au moment de la conception tous les opérateurs qui seront éventuellement activés par la 
publication d'une information par une source. De plus, notre stratégie de génération assure que 
ces propriétés seront préservées au niveau de Pimplémentation. 

Les contrats d'interactions permettent aussi de vérifier des invariants d'interactions qui sont 
des propriétés vérifiées à tout moment de l'exécution. Nous caractérisons la progression d'une 
application SCC par son flot de données et utilisons la logique temporelle linéaire (LTL) pour 
définir ces invariants. Pour vérifier ces invariants, une architecture DiaSpec est automatiquement 
traduite en un modèle pour le model checker SPIN. Si un invariant n'est pas satisfait, SPIN donne 
un contre exemple sous la forme d'une trace d'exécution qui guide l'architecte dans la correction de 
son architecture. Cet exemple montre que les contrats d'interactions rendent explicites les concepts 
clés du style architectural SCC et donc facilitent les analyses sur le flot de données. 

5 Conclusion 

Nous avons introduit la notion de contrat d'interactions exprimant les interactions autorisées au 
sein d'une architecture SCC. Les contraintes exprimées par ces contrats d'interactions permettent 
des vérifications et guident Pimplémentation de l'architecture, tout en assurant la conformité. 



